Assign single object number to DOORS Table

In our workflow, we want to be able to export a word document to DOORS and maintain consistent formatting. We've had decent success using the DOOR Export option within word via attaching the doors.dot template. We have no requirements/traceability issues with the tables since the shall's are contained in other objects and the tables contain supplemental information.

The problem we have with this approach is in DOORS after the export. Every table in the word document is generated as a DOORS Table, and every cell in each DOORS table is assigned a unique number. This leads to a huge increase in the number of objects in the module. Since we have no need to track the history of individual cells, and prefer to simply track the history of the table as a whole, with a single attribute set, this is not ideal.

My question is this - Is it possible to set DOORS tables so each table is only assigned a single object number and set of attributes? If so, how do I do it?

Note: OLE Tables are not an idea solution for us as they are not searchable. I have already tested a method where I convert the word tables to OLE objects before doing the export, which creates them in the DOORS module as OLE objects. This approach does fix the issue in that it places the table into a single DOORS object, but it presents other problems as well.

Any help is appreciated! Thank you in advance.
SystemAdmin - Fri Mar 01 13:49:48 EST 2013

Re: Assign single object number to DOORS Table
SystemAdmin - Fri Mar 01 17:19:45 EST 2013

Each DOORS table has a hidden Table Header object which represents where the table is located in the module.

To see this Table Header object, go to the View > Show menu and deselect the "Table Cells" option. Whilst this will hide the table cells, it will also reveal the Table Header Object and its UID. It has attributes just like any other object. The problem is that you can't have your cake and eat it too - I don't know of a way in which you can display both the Table Header object and the table cells at the same time.

If you're using captions for for your tables then maybe use the object that has the caption as being representative of the table for both UID and attributes values.


Paul Miller,
Melbourne, Australia

Re: Assign single object number to DOORS Table
SystemAdmin - Fri Mar 01 17:53:36 EST 2013

I am not sure I understood your problem.

yes, each table, each header and each cell is an object in DOORS and gets its own absolute number.

But why do you care about the number of objects stored in the module? When you say "… need to track the history …":
a) why would you want to do this? Normally you should only care about requirements - which you could designate by some attribute like "Object Type" or "Requirement Type".
b) if you really want to track when something in the table has changed, the question is: how do you do this? If you have something like a report which tells you the differences, you could write a script which summarizes the changes in one place.

Regards
Mike

P.S.: Do not fall into the pit of seeing the absolute number as having any meaning besides giving uniqueness to the object. if one object has number 5 and the following object has number 345244 there is no general problem.

Re: Assign single object number to DOORS Table
SystemAdmin - Fri Mar 01 17:57:04 EST 2013

SystemAdmin - Fri Mar 01 17:53:36 EST 2013
I am not sure I understood your problem.

yes, each table, each header and each cell is an object in DOORS and gets its own absolute number.

But why do you care about the number of objects stored in the module? When you say "… need to track the history …":
a) why would you want to do this? Normally you should only care about requirements - which you could designate by some attribute like "Object Type" or "Requirement Type".
b) if you really want to track when something in the table has changed, the question is: how do you do this? If you have something like a report which tells you the differences, you could write a script which summarizes the changes in one place.

Regards
Mike

P.S.: Do not fall into the pit of seeing the absolute number as having any meaning besides giving uniqueness to the object. if one object has number 5 and the following object has number 345244 there is no general problem.

> each table, each header and each cell is an object

make this: each table, each row and each cell […]

Re: Assign single object number to DOORS Table
BillTidy - Fri Mar 08 09:31:14 EST 2013

I can't remember now if it's the 'First Law of DOORS' but I think so. Anyway, it's right up there with the other "Don't try it" biggy - shareable edit mode. Basically that particular law states "You will only experience extreme pain and suffering if you use DOORS tables".

You have to think out of the box and remember that one of the strengths of a tool like DOORS is that you can separate format from content (unlike Excel and Word for example). What you want is to have 1 identifier for a set of attributes in DOORs but to print out those attributes in a tabular form in Word when you export that data.

What you do is NOT create a DOORS table (or import a Word table into DOORS as a DOORS table). Instead, create attributes for the table columns and a view in which you make those attributes visible so you can enter the data. You also need to have an attribute which identifies the row type - an enumeration with values something like "requirement, requirement table, information,..."). For those rows that you want to print out as a table in Word, you set the row type to "requirement table" for example. Then, when you are exporting the data with something like an RPE template (or previously a WEXP template), you print out in a table format for objects of row type "requirement table".

Re: Assign single object number to DOORS Table
kbmurphy - Fri Mar 08 10:44:31 EST 2013

BillTidy - Fri Mar 08 09:31:14 EST 2013
I can't remember now if it's the 'First Law of DOORS' but I think so. Anyway, it's right up there with the other "Don't try it" biggy - shareable edit mode. Basically that particular law states "You will only experience extreme pain and suffering if you use DOORS tables".

You have to think out of the box and remember that one of the strengths of a tool like DOORS is that you can separate format from content (unlike Excel and Word for example). What you want is to have 1 identifier for a set of attributes in DOORs but to print out those attributes in a tabular form in Word when you export that data.

What you do is NOT create a DOORS table (or import a Word table into DOORS as a DOORS table). Instead, create attributes for the table columns and a view in which you make those attributes visible so you can enter the data. You also need to have an attribute which identifies the row type - an enumeration with values something like "requirement, requirement table, information,..."). For those rows that you want to print out as a table in Word, you set the row type to "requirement table" for example. Then, when you are exporting the data with something like an RPE template (or previously a WEXP template), you print out in a table format for objects of row type "requirement table".

Slightly off topic, but I've got modules with thousands of objects using shareable edit, and have only had a couple of minor problems over several years. It can be done.